Accident-severity scoring device, method, and system

ABSTRACT

The present disclosure provides a device associated with a vehicle, the device including a set of sensors configured to generate a set of data associated with the vehicle; and one or more controllers configured to analyze the set of data to determine if an accident involving the vehicle has occurred, responsive to a determination that an accident involving the vehicle has occurred, determine an accident-severity score associated with the vehicle involved in the accident, the accident-severity score being based on a set of accident-severity scoring rules and at least a portion of the set of data, and transmit an output signal representative of the determined accident-severity score.

FIELD OF THE DISCLOSURE

The present disclosure relates generally to a device and system fordetermining the accident severity of a vehicle, such as, for example,vehicle damage, passenger injury, emergency response needed, and thelike, and transmitting associated data. More particularly, the presentdisclosure relates to a portable device and system for measuring dataassociated with vehicle movement and position, determining an accidentor other notable event, and transmitting data and/or alerts based on thedetermined status and/or measured data.

BACKGROUND OF THE DISCLOSURE

Conventional vehicle status or accident detectors are often used topromote safer driving and to allow emergency response professionals torespond faster to accidents. These conventional detectors are oftenbuilt into vehicles, therefore making it difficult to continuouslymeasure vehicle status of users who may have multiple vehicles.Additionally, the existing conventional detectors often measure only asingle parameter (e.g., speed), and are unable to measure multipleparameters at once to allow for an early detection of a potentialvehicle or driver problems that may be indicated by abnormities inmultiple parameters when they are analyzed together. Furthermore, thelack of portable and scalable vehicle status and accident detectorsoften leads to overuse of emergency responder resources (e.g., emergencyresponse professionals' time) which can be better spent on e.g.,responding to more urgent or dangerous accidents, and the like.

An unfulfilled need exists for a means to measure severity of theaccident in a fast and easy to understand manner.

BRIEF SUMMARY OF THE DISCLOSURE

An aspect of the present disclosure provides a device associated with avehicle, the device including: a set of sensors configured to generate aset of data associated with the vehicle; and one or more controllersconfigured to: (i) analyze the set of data to determine if an accidentinvolving the vehicle has occurred, (ii) responsive to a determinationthat an accident involving the vehicle has occurred, determine anaccident-severity score associated with the vehicle involved in theaccident, the accident-severity score being based on a set ofaccident-severity scoring rules and at least a portion of the set ofdata, and (iii) transmit an output signal representative of thedetermined accident-severity score.

In an embodiment of the present disclosure, one or more controllers maybe further configured to analyze a second set of data generated by asecond set of sensors included in a mobile device positioned within thevehicle to determine if an accident involving the vehicle has occurred,the second set of data being received by the device via a communicationsmodule of the device.

The determination of the accident-severity score may be further based onat least a portion of the second set of data.

The accident-severity score may further be based on at least one of thefollowing criteria: Actual Speed of the vehicle; Speed of the vehicleverses posted speed limit of the road, route, path, highway, and thelike, where the vehicle is traveling; Gyroscope and/or Accelerometerdata of the vehicle; Aggregated averages of data collected from thevehicle or driver of said vehicle; Aggregated averages of data vs.baseline composite aggregated average; Data based off gross weight ofthe vehicle; Data based off cargo or a number of passengers in thevehicle; Data based off type of vehicle (e.g., truck, minibus, van, bigrig, industrial vehicle, passenger vehicle, and the like); GPS data andderived data; Time of day when the vehicle gets into an accident;Specific accelerometer data (e.g., hard break, acceleration,deceleration, and the like) of the vehicle; comparison of all factorsagainst other drivers by having the system (or the device) include amachine learning algorithm that determines a common (or baseline)profile for a safe driver, then highlight deviations from said profile(or deviations from the standard profile of that specific driver).

The device may be in combination with a computing device, wherein thecomputing device may be configured to (i) receive the output signal fromthe device and (ii) based on a set of accident-response rules and theaccident-severity score, determine the appropriate amount of resourcesto be dispatched to an accident site involving the vehicle. Theappropriate amount of resources may include a number of emergencyvehicles, type of emergency vehicle to be dispatched, a type ofemergency responder (e.g., nurse, doctor, paramedic, police) to bedispatched, and the like.

Another aspect of the presented disclosure provides a system for use indetermining an appropriate amount of resources to be dispatched to anaccident site involving a vehicle operated by a user, the systemincludes: a mobile device positioned within the vehicle and beingassociated with the user operating the vehicle, the mobile deviceincluding a first set of sensors configured to generate a first set ofdata associated with the vehicle; a device positioned in the vehicle andcommunicatively connected with the mobile device such that the device isconfigured to receive at least a portion of the first set of data fromthe mobile device, the device including a second set of sensorsconfigured to generate a second set of data associated with the vehicle,responsive to the device detecting an occurrence of an accidentinvolving the vehicle, the device is configured to: (i) determine anaccident-severity score associated with the vehicle involved in theaccident, the accident-severity score being based on a set ofaccident-severity scoring rules, at least a portion of the first set ofdata, at least a portion of the second set of data, or any combinationthereof, and (ii) transmit an output signal representative of thedetermined accident-severity score; and a computing device configured to(i) receive the output signal from the device and (ii) based on a set ofaccident-response rules and the accident-severity score, determine theappropriate amount of resources to be dispatched to the accident siteinvolving the vehicle.

The determination of the appropriate amount of resources may be furtherbased on additional information, the additional information including atype of the vehicle, biometric information associated with the user thatwas collected by one or more sensors prior to the accident, after theaccident, or both, an age of the user, a weight of the user, a sex ofthe user, a medical condition of the user, or any combination thereof.

The additional information may be received by the computing device fromthe device, from the mobile device, or a combination thereof.

The device may be further configured to detect whether an accidentinvolving the vehicle has occurred based on at least a portion of thefirst set of data, at least a portion of the second set of data, or acombination thereof.

The system in accordance with the present disclosure, responsive to thedevice detecting the occurrence of the accident involving the vehicle,the device may be further configured to transmit an instruction to themobile device to (i) activate a video camera of the mobile device, (ii)activate a microphone of the mobile device, or (iii) both (i) and (ii).

The system in accordance with the present disclosure, responsive to thedevice detecting the occurrence of the accident involving the vehicle,the device may be further configured to transmit an instruction to themobile device to display, on a display device of the mobile device,insurance information.

The determination of the accident-severity score may be at leastpartially based on (i) a determined G-force imparted on the vehicle,(ii) a determined direction of impact imparted on the vehicle, (iii) adetermined roll position of the vehicle, (iv) a determined yaw positionof the vehicle, (v) a determined change in vehicle facing position, or(vi) any combination thereof.

The first set of sensors may include a movement sensor, a positionsensor, an image sensor, an electronic nose sensor, a vital signdetector, an audio sensor, or any combination thereof.

The movement sensor may include an accelerometer, a gyroscope, amagnetometer, or any combination thereof.

The position sensor may include a global positioning system (GPS), aGLONASS, a BeiDou, a Galileo, a NAVIC, a QZSS, a DORIS, a geo-satelliteservice (GSS), a cellular location data detector, a wireless locationtriangulation device, or any combination thereof.

The second set of sensors may include a movement sensor, a positionsensor, an image sensor, an electronic nose sensor, a vital signdetector, an audio sensor, or any combination thereof.

The movement sensor may include an accelerometer, a gyroscope, amagnetometer, or any combination thereof.

The position sensor may include a global positioning system (GPS), aGLONASS, a BeiDou, a Galileo, a NAVIC, a QZSS, a DORIS, a geo-satelliteservice (GSS), a cellular location data detector, a wireless locationtriangulation device, or any combination thereof.

Prior to the transmitting of the output signal, the device is furtherconfigured to determine, via the electronic nose sensor, if a substanceis present in the vehicle and responsive to the device determining thatthe substance is present in the vehicle, modify the determinedaccident-severity score.

The substance may include gasoline, fuel, natural gas, smoke, fire, orany combination thereof. The substance may also include any otherharmful or toxic substance as pre-programmed by the user.

Prior to the transmitting of the output signal, the device may befurther configured to determine, via the position sensor, a geo-locationof the vehicle and responsive to the device determining the geo-locationof the vehicle, modify the determined accident-severity score.

The determining of the geo-location may include a determination of (i)whether the vehicle is located on a road having a speed limit that isgreater than or less than certain (predetermined or pre-calculated)miles per hour, (ii) whether the vehicle is more than or less thancertain distance from a hospital, or (iii) both (i) and (ii).

In yet another aspect of the present disclosure, a method of determiningan appropriate amount of resources to be dispatched to an accident siteinvolving a vehicle operated by a user is disclosed. The method includesgenerating, via a first set of sensors of a device, a first set of dataassociated with the vehicle; receiving, via a communications module ofthe device, a second set of data, the second set of data being generatedvia a second set of sensors of a mobile device positioned within thevehicle; detecting an occurrence of an accident involving the vehicle;responsive to the detecting, determining an accident-severity scoreassociated with the vehicle involved in the accident, theaccident-severity score being based on a set of accident-severityscoring rules, at least a portion of the generated first set of data, atleast a portion of the received second set of data, or any combinationthereof; transmitting, via the communications module of the device, anoutput signal representative of the determined accident-severity score;and determining, based on a set of accident-response rules and theaccident-severity score, the appropriate amount of resources to bedispatched to the accident site involving the vehicle.

In yet another aspect of the present disclosure, a system for use indetermining an accident-severity score for an accident involving a firstvehicle operated by a first user and a second vehicle operated by asecond user is disclosed. The system includes a first device positionedin the first vehicle, the first device including a first set of sensorsconfigured to generate a first set of data associated with the firstvehicle, responsive to the first device detecting an occurrence of afirst accident involving the first vehicle, the first device isconfigured to: (i) determine a first accident-severity score associatedwith the first vehicle involved in the first accident, the firstaccident-severity score being based on a set of accident-severityscoring rules and a first portion of the first set of data, and (ii)transmit a second portion of the first set of data and a first outputsignal representative of the determined first accident-severity score; asecond device positioned in the second vehicle, the second deviceincluding a second set of sensors configured to generate a second set ofdata associated with the second vehicle, responsive to the second devicedetecting an occurrence of a second accident involving the secondvehicle, the second device is configured to: (i) determine a secondaccident-severity score associated with the second vehicle involved inthe second accident, the second accident-severity score being based onthe set of accident-severity scoring rules and a first portion of thesecond set of data, and (ii) transmit a second portion of the second setof data and a second output signal representative of the determinedsecond accident-severity score; a computing device configured to (i)receive the first output signal from the first device, (ii) receive thesecond output signal from the second device, (iii) receive the secondportion of the first set of data, (iv) receive the second portion of thesecond set of data, (v) determine, based at least in part on thereceived second portion of the first set of data and the received secondportion of the second set of data, that the first accident is the sameas the second accident, and (vi) responsive to the determination thatthe first accident is the same as the second accident, modify thedetermined first accident-severity score, the determined secondaccident-severity score, or both.

The modification is based at least in part on additional information,the additional information may include a type of the first vehicle, atype of the second vehicle, biometric information associated with thefirst user, biometric information associated with the second user, anage of the first user, an age of the second user, a weight of the firstuser, a weight of the second user, a sex of the first user, a sex of thesecond user, a medical condition of the first user, a medical conditionof the second user, or any combination thereof.

The additional information may be received by the computing device fromthe first device, from the second device, or a combination thereof.

The computing device may be further configured to determine anappropriate amount of resources to be dispatched to the accident siteinvolving the first vehicle and the second vehicle based on (i) a set ofaccident-response rules, (ii) the first accident-severity score, (iii)the modified first accident-severity score, (iv) the secondaccident-severity score, (v) the modified second accident-severityscore, (vi) or any combination thereof.

The first portion of the first set of data may be different than thesecond portion of the first set of data and wherein the first portion ofthe second set of data may be different than the second portion of thesecond set of data.

In another embodiment of the present disclosure, the system may includea first mobile device positioned within the first vehicle and beingassociated with the first user operating the first vehicle, the firstmobile device including a third set of sensors configured to generate athird set of data associated with the first vehicle, the first mobiledevice being communicatively connected with the first device such thatthe first device is configured to receive at least a portion of thethird set of data from the first mobile device; and a second mobiledevice positioned within the second vehicle and being associated withthe second user operating the second vehicle, the second mobile deviceincluding a fourth set of sensors configured to generate a fourth set ofdata associated with the second vehicle, the second mobile device beingcommunicatively connected with the second device such that the seconddevice is configured to receive at least a portion of the fourth set ofdata from the second mobile device.

The first accident-severity score may be further based on at least aportion of the third set of data and wherein the secondaccident-severity score is further based on at least a portion of thefourth set of data.

The system in accordance with the present disclosure, responsive to thedetermination that the first accident is the same as the secondaccident, the computing device may be further configured to transmitfirst information associated with the first user to the second mobiledevice and transmit second information associated with the second userto the first mobile device.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a front isometric view of a device according to animplementation of the present disclosure.

FIG. 2 is a rear isometric view of the device of FIG. 1.

FIG. 3 is a front isometric view of a device according to anotherimplementation of the present disclosure.

FIG. 4 is a block diagram representing a host system according to animplementation of the present disclosure.

FIG. 5 is a block diagram representing an implementation of a deviceconfiguration according to the present disclosure.

FIG. 6 is a block diagram representing another implementation of adevice configuration according to the present disclosure.

FIG. 7 is a block diagram representing another implementation of adevice configuration according to the present disclosure.

FIG. 8 is a block diagram representing internal components of anexemplary device according to an implementation of the presentdisclosure.

FIG. 9 is a flowchart representing an implementation of an exemplarymethod for detecting a vehicle status, more particularly an accident, inaccordance with the present disclosure.

FIG. 10 is a block diagram representing a host system according toanother implementation of the present disclosure.

FIG. 11 is a flowchart representing an implementation of anotherexemplary method for detecting a vehicle status, more particularly anaccident, in accordance with the present disclosure.

FIG. 12 is a flowchart representing an implementation of an exemplarymethod for real time driver feedback and third party notifications inaccordance with the present disclosure.

FIG. 13 is a flowchart representing an implementation of an exemplarymethod for automatic speed limit database updating in accordance withthe present disclosure.

DETAILED DESCRIPTION OF THE DISCLOSURE

The disclosure and the various features and advantageous details thereofare explained more fully with reference to the non-limitingimplementations and examples that are described and/or illustrated inthe accompanying drawings, the “ATTACHMENT”, and detailed in thefollowing description. It should be noted that the features illustratedin the drawings and the ATTACHMENT are not necessarily drawn to scale,and features of one implementation may be employed with otherimplementations as any person skilled in the art would recognize, evenif not explicitly stated herein. Descriptions of well-known componentsand processing techniques may be omitted so as to not unnecessarilyobscure the implementations of the disclosure. The examples used hereinare intended merely to facilitate an understanding of ways in which thedisclosure may be practiced and to further enable those of skill in theart to practice the implementations of the disclosure. Accordingly, theexamples and implementations herein should not be construed as limitingthe scope of the disclosure.

Throughout the specification and claims, the following terms take atleast the meanings explicitly associated herein, unless the contextdictates otherwise. The meanings identified below do not necessarilylimit the terms, but merely provide illustrative examples for the terms.The meaning of “a,” “an,” and “the” may include plural references, andthe meaning of “in” may include “in” and “on.” The phrase “in oneimplementation,” as used herein does not necessarily refer to the sameimplementation

The term “coupled” means at least either a direct electrical connectionbetween the connected items or an indirect connection through one ormore passive or active intermediary devices. The term “circuit” means atleast either a single component or a multiplicity of components, eitheractive and/or passive, that are coupled together to provide a desiredfunction. The term “signal” as used herein may include any meanings asmay be understood by those of ordinary skill in the art, including atleast an electric or magnetic representation of current, voltage,charge, temperature, data or a state of one or more memory locations asexpressed on one or more transmission mediums, and generally capable ofbeing transmitted, received, stored, compared, combined or otherwisemanipulated in any equivalent manner.

Terms such as “providing,” “processing,” “supplying,” “determining,”“calculating” or the like may refer at least to an action of a computersystem, computer program, signal processor, logic or alternative analogor digital electronic device that may be transformative of signalsrepresented as physical quantities, whether automatically or manuallyinitiated.

A “computer,” as used in this disclosure, means any machine, device,circuit, component, or module, or any system of machines, devices,circuits, components, modules, or the like, which are capable ofmanipulating data according to one or more instructions, such as, forexample, without limitation, a processor, a microprocessor, a centralprocessing unit, a general purpose computer, a cloud, a super computer,a personal computer, a laptop computer, a palmtop computer, a mobiledevice, a tablet computer, a notebook computer, a desktop computer, aworkstation computer, a server, or the like, or an array of processors,microprocessors, central processing units, general purpose computers,super computers, personal computers, laptop computers, palmtopcomputers, mobile devices, tablet computers, notebook computers, desktopcomputers, workstation computers, servers, or the like.

A “server,” as used in this disclosure, means any combination ofsoftware and/or hardware, including at least one application and/or atleast one computer to perform services for connected clients as part ofa client-server architecture. The at least one server application mayinclude, but is not limited to, for example, an application program thatcan accept connections to service requests from clients by sending backresponses to the clients. The server may be configured to run the atleast one application, often under heavy workloads, unattended, forextended periods of time with minimal human direction. The server mayinclude a plurality of computers configured, with the at least oneapplication being divided among the computers depending upon theworkload. For example, under light loading, the at least one applicationcan run on a single computer. However, under heavy loading, multiplecomputers may be required to run the at least one application. Theserver, or any if its computers, may also be used as a workstation.

A “database,” as used in this disclosure, means any combination ofsoftware and/or hardware, including at least one application and/or atleast one computer. The database may include a structured collection ofrecords or data organized according to a database model, such as, forexample, but not limited to at least one of a relational model, ahierarchical model, a network model or the like. The database mayinclude a database management system application (DBMS) as is known inthe art. The at least one application may include, but is not limitedto, for example, an application program that can accept connections toservice requests from clients by sending back responses to the clients.The database may be configured to run the at least one application,often under heavy workloads, unattended, for extended periods of timewith minimal human direction.

A “communications network,” as used in this disclosure, means a wiredand/or wireless medium that conveys data or information between at leasttwo points. The wired or wireless medium may include, for example, ametallic conductor link, a radio frequency (RF) communication link, anInfrared (IR) communication link, telecommunications networks, anoptical communication link, internet (wireless and wired) or the like,without limitation. The RF communication link may include, for example,WiFi, WiMAX, IEEE 802.11, DECT, 0G, 1G, 2G, 3G, 4G, 5G or futurecellular standards, Bluetooth, Bluetooth Low Energy, NFC, ultrasound,induction, laser (or similar optical transmission) and the like.

A “computer-readable storage medium,” as used in this disclosure, meansany medium that participates in providing data (for example,instructions) which may be read by a computer. Such a medium may takemany forms, including non-volatile media, volatile media, andtransmission media. Non-volatile media may include, for example, opticalor magnetic disks, flash memory, and other persistent memory. Volatilemedia may include dynamic random access memory (DRAM). Transmissionmedia may include coaxial cables, copper wire and fiber optics,including the wires that comprise a system bus coupled to the processor.Transmission media may include or convey acoustic waves, light waves andelectromagnetic emissions, such as those generated during radiofrequency (RF) and infrared (IR) data communications. Common forms ofcomputer-readable media include, for example, a floppy disk, a flexibledisk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM,DVD, any other optical medium, punch cards, paper tape, any otherphysical medium with patterns of holes, a RAM, a PROM, an EPROM, aFLASH-EEPROM, any other memory chip or cartridge, a carrier wave asdescribed hereinafter, or any other medium from which a computer canread. The computer-readable medium may include a “Cloud,” which includesa distribution of files across multiple (e.g., thousands of) memorycaches on multiple (e.g., thousands of) computers.

Various forms of computer readable media may be involved in carryingsequences of instructions to a computer. For example, sequences ofinstruction (i) may be delivered from a RAM to a processor, (ii) may becarried over a wireless transmission medium, and/or (iii) may beformatted according to numerous formats, standards or protocols,including, for example, WiFi, WiMAX, IEEE 802.11, DECT, 0G, 1G, 2G, 3Gor 4G cellular standards, Bluetooth, or the like.

A “network,” as used in this disclosure means, but is not limited to,for example, at least one of a local area network (LAN), a wide areanetwork (WAN), a metropolitan area network (MAN), a personal areanetwork (PAN), a campus area network, a corporate area network, a globalarea network (GAN), a broadband area network (BAN), a cellular network,the Internet, the cloud network, or the like, or any combination of theforegoing, any of which may be configured to communicate data via awireless and/or a wired communication medium. These networks may run avariety of protocols not limited to TCP/IP, IRC, SSL, TLS, UDP, or HTTP.

Devices that are in communication with each other need not be incontinuous communication with each other, unless expressly specifiedotherwise. In addition, devices that are in communication with eachother may communicate directly or indirectly through one or moreintermediaries.

Although process steps, method steps, algorithms, or the like, may bedescribed in a sequential order, such processes, methods and algorithmsmay be configured to work in alternate orders. In other words, anysequence or order of steps that may be described does not necessarilyindicate a requirement that the steps be performed in that order. Thesteps of the processes, methods or algorithms described herein may beperformed in any order practical. Further, some steps may be performedsimultaneously.

When a single device or article is described herein, it will be readilyapparent that more than one device or article may be used in place of asingle device or article. Similarly, where more than one device orarticle is described herein, it will be readily apparent that a singledevice or article may be used in place of the more than one device orarticle. The functionality or the features of a device may bealternatively embodied by one or more other devices which are notexplicitly described as having such functionality or features.

Referring generally to FIGS. 1-13, various implementations of systems,devices, and methods in accordance with the present disclosure may bedescribed herein. Where the various figures may describe implementationssharing various common elements and features with other implementations,similar elements and features are given the same reference numerals andredundant description thereof may be omitted below.

Generally stated, a local device is configured in accordance with thepresent disclosure to detect a vehicle status, such as for example anaccident or even unsafe driving conditions, and provide output signalsto local and/or remote devices or indicators representative of vehicledata and vehicle status. A host system may include a central serverconfigured to send and receive data to and from the device, and a userinterface such as for example a hosted web site generated via thecentral server or a program application downloaded to and generated froma remote user device such as for example a smartphone, the userinterface being optionally configured to display the vehicle data andstatus received from the local device and/or to receive remote userinput for programming the local device. The local device may in variousimplementations be a dedicated or standalone device for use in (andpowered by a power source associated with) a vehicle such as for examplea cigarette lighter adapter as further described below, or may be acomputing device having numerous alternative uses such as for example asmartphone running a dedicated program application.

Referring first to FIGS. 1-2, front and rear isometric views are shownrepresenting an implementation of a standalone local device 10 inaccordance with the present disclosure. An integral housing 12 is shownhere which includes power supply terminals 14 on a first end defining acigarette lighter plug for coupling to an onboard power supply of avehicle such as a cigarette lighter socket, although in variousimplementations (not shown) the local device 10 may include alternativepower supply terminals or power input means to receive power from analternative local power source.

As the local device protrudes outward from the cigarette lighter socketof a vehicle when it is plugged in, in other implementations (not shown)it may be desirable that the housing 12 include a bendable, rotatable orotherwise moveable portion which may allow an opposing or distal end ofthe housing 12 with respect to the cigarette lighter plug leads 14 to bepositioned in a practical fashion and thereby accommodate varyingvehicle interior designs. In such implementations, the moveable portionof the housing 12 may further include a locking mechanism such as alatch that prevents the moveable portion from moving relative to thefirst end (i.e., the cigarette lighter plug) once it is locked intoposition.

The distal end of the device 10 as shown in FIGS. 1-2 further includes abutton 16 as a local user interface occupying some portion of a face (orotherwise disposed along a length of the housing 12) which may be usedfor engaging the device 10 and causing internal control circuitry toperform predetermined functions as further described below. The distalend may further include other visual indicators 18 such as for example aplurality of LED outputs 18 located within the button 16 (as shown inFIG. 1) or on a portion of a face of the distal end proximate the button16 (as shown in FIG. 3), or any other practical and visually accessiblelocation about the housing 12. The various visual indicators 18 may beconfigured to indicate to a driver that the device is functional, or maybe an indicator of driving performance or some other predeterminedindicator as programmed into the device 10. In a particular exemplaryimplementation, the device 10 may include three lights arranged to bevisible to a driver when plugged into the cigarette lighter socket andcolored green, yellow and red to indicate driving performance.

Another portion of the housing 12 may include slits, holes or by otheror other equivalent openings 20 to allow for audio input and output withrespect to internal components such as a microphone, etc. In variousimplementations (not shown) the device 10 may contain a connector and/orcable for the purpose of physically connecting to another device, suchas a 30-pin cable which may or may not be detachable from the device 10.The device 10 may further contain a small pin-sized button (not shown)that is not easily depressed for the purposes of programming the device10.

Referring now to FIG. 4, an exemplary hosted system 40 according to animplementation of the present disclosure may include a server 44functionally and communicatively linked to the local device 10 via acommunications network 42. Alternatively, a distributed server networkmay be used to provide or facilitate the same functions.

The hosted server 44 in the example shown may include without limitationone or more processors 46, a computer-readable memory medium 48 and adatabase 50. The term “computer-readable memory medium” as used hereinmay refer to any non-transitory medium alone or as one of a plurality ofnon-transitory memory media within which is embodied a computer programproduct that includes processor-executable software, instructions orprogram modules which upon execution may provide data or otherwise causethe server 44 or equivalent computer system to implement subject matteror otherwise operate in a specific manner as further defined herein. Itmay further be understood that more than one type of memory media may beused in combination to conduct processor-executable software,instructions or program modules from a first memory medium upon whichthe software, instructions or program modules initially reside to aprocessor for execution.

“Memory media” may further include without limitation transmission mediaand/or storage media. “Storage media” may refer in an equivalent mannerto volatile and non-volatile, removable and non-removable media,including at least dynamic memory, application specific integratedcircuits (ASIC), chip memory devices, optical or magnetic disk memorydevices, flash memory devices, or any other medium which may be used tostored data in a processor-accessible manner, and may unless otherwisestated either reside on a single computing platform or be distributedacross a plurality of such platforms. “Transmission media” may includeany tangible media effective to permit processor-executable software,instructions or program modules residing on the media to be read andexecuted by a processor, including without limitation wire, cable,fiber-optic and wireless media such as is known in the art.

The software products residing on the hosted server 44 may be effectiveto for example generate a user interface 52 such as a website andassociated web pages to display data received from the local device 10or receive data from a user for programming the local device 10. Datafrom the local device 10 may further be stored in the database 50 in anaccount associated with a user and used for data trending or otherintermediate- to long-term statistical analysis or reporting. The hostedserver 44 may further provide software products for downloading via theuser interface 52 or by other known transmission media (or via thirdparty servers such as for example conventionally known mobileapplication markets) to a user device 54 such that upon execution of ahost-provided program the user may be able to remotely access data fromthe local device 10 or otherwise program the local device 10 via acommunications network 42 without further requiring the use of the hostsystem 40 as an intermediary. The remote user device 54 may include anyof a number of computing devices including desktops, laptops, tablets,smart-phones, etc., as operable to download the software products andexecute the associated program features as described above. The userdevice 54 as represented in FIG. 4 may in various implementations covermore than just a device associated with a user wishing to view dataassociated with the vehicle, but also may cover devices forpredetermined contacts or emergency medical service personnel that maybe programmed with respect to the local device 10 as automatic contactsin the event of an emergency.

Referring now to FIG. 8, the various internal components of an exemplarydevice 10 in accordance with an implementation of the present disclosuremay include a control unit 62 such as a conventional microcontrollerhaving an I/O module 64, a processing unit 66, a memory 68 effective tostore for example device parameters 70 and relevant access or securitycodes 72 and a memory 74 upon which resides instructions or programmodules 76 such as for example a data filtering module 78, a speedcalculation module 80, a sound analysis module 82 and a vehicle statusdetermination module 84.

While the terms “controller” or “control unit” as used interchangeablyherein may typically refer to a microcontroller designed as describedabove and further programmed to perform functions as further definedherein, it may in various alternative implementations refer to forexample a general microprocessor, an application specific integratedcircuit (ASIC), a digital signal processor (DSP), a field programmablegate array, and/or various alternative blocks of discrete circuitry asare known in the art to perform functions as defined herein when soconfigured.

It may further be understood that the internal components of the controlunit are not limited to those described herein, that some of thecircuitry or program modules described herein may in fact be redundantor unnecessary for a particular application, and that in variousimplementations two or more of the program modules described may in factdescribe a single program module effective to perform like functions.

Further residing within or about the device housing(s) 10 andfunctionally linked to the controller 62 may be without limitation avehicle motion sensor 86 such as an accelerometer and/or gyroscope, aposition sensor 88 such as a conventional GPS receiver, a communicationsdevice 90 such as a cellular modem, a local user interface 92 such asfor example the button described above, a microphone 94 or equivalentaudio sensor, a display unit 96 such as for example the LEDs or othervisual outputs, and an audio output 98 effective to for example beep,ring or otherwise alert the driver based on a programmed function. Asbut one further example, the audio output 98 may be effective to providereal-time voice functionality in addition to programmed alerts, such asmay be desirable in the event of an emergency by providing emergencypersonnel, 911 operators, etc., with a direct outlet for communicatingvia the local device with a driver. The real-time may mean same time orsubstantially same time (e.g., within milliseconds). The real-time maymean greater or less than 1 millisecond.

Even further residing within the device housing 10 as represented inFIG. 8 are an internal power supply 85 which may be coupled to theexternal (onboard) power source 56 via for example the various contactterminals 14, and an energy storage device 87 such as for example abattery or a capacitor. In various implementations, the controller maybe effective to determine whether the removal of input power from thepower source (via the contact terminals) is a result of being forciblyejected from the power source such as may be the case in an accident, ormerely having been removed manually by the user. In the event that thedevice 10 is determined to have been forcibly ejected (removed from thepower source), the power supply 85 may be triggered to switch from thepower source 85 as a primary power input source to the energy storagedevice 87 as a secondary source, which may be configured to store atleast enough power that the microcontroller will have a period of timeto generate and transmit an event alert such as a voice call to a remoteentity (i.e., 911). The device 10 may preferably include programinstructions effective to execute a process for determining forcibleejection, which may in certain implementations include confirming anaccident condition in a manner substantially as recited below andcoincident with detection of the lack of power from the primary source56. In alternative implementations the process for determining forcibleejection may be substantially independent from or otherwise unrelated tothe processes described herein for determining an accident condition.

It may be understood by those of skill in the art that one or more ofthe components described above as residing within the housing may becombined into a single component having the equivalent features. Forexample, a communications device could within the scope of the presentdisclosure further potentially serve as the positioning sensor. It mayfurther be understood that one or more of the above-described componentsmay in fact be unnecessary or redundant for a particular applicationstill within the scope of the present disclosure, and the list ofcomponents is in no way intended as limiting.

Referring now to FIGS. 5-7, various implementations of a local deviceconfiguration may be briefly described.

In one implementation as represented in FIG. 5, a local device 10 isfixed in position when plugged into the onboard power source 56 andeffective to transmit and receive data to and from a remote device(i.e., smartphone, desktop, tablet, etc.) and/or the host server 44 viaa communications network as substantially described above.

In another implementation as represented in FIG. 6 (i.e., the so-called“pregnant snake” configuration) the device 10 is divided up into a firstdevice module 58 which is coupled to the onboard power source 56 and asecond device module 60 which is able to communicate with the remotedevices 54 and/or the hosted server 44 via the communications network42. Several of the internal components such as for example the GPSreceiver, cellular modem, microcontroller and accelerometer may residein the second module 60 and be electrically coupled to the first module58 and the associated power supply via a cord. The first module 58 maystill have a front face upon which the button is supported, but in thisconfiguration the first module 58 or otherwise the portion of the device10 which is physically coupled to the cigarette lighter socket may besmaller as needed or otherwise desirable. The second module 60 in thisimplementation would still need to be rigidly attached to the vehicleinterior by a bracket or equivalent attachment mechanism in order forthe accelerometer to function reliably. To escape the need to securelystabilize the components not contained in the first module 58, however,the accelerometer could alternatively be placed into the first module 58and thereby fixed in position relative to the vehicle while theremaining components are not fixed but remain electrically coupled tothe power supply via a wire.

In another implementation as represented in FIG. 7, the local device 10may embody two separate devices 10 a, 10 b respectively coupled to twoseparate onboard power sources 56 a, 56 b around the vehicle. Either orboth of the separate devices may be further separated into a firstmodule 58 a, 58 b and a second module 60 a, 60 b as described withrespect to the implementation shown in FIG. 6. Through RF technology oran equivalent these otherwise independent devices may communicate witheach other and function as a single device or local system havingredundancy features such as for example confirmation of a detectedvehicle status.

As previously described or otherwise implied above, a local device 10 inaccordance with various implementations of the present disclosure maycommunicate and interact with other devices via a connector and/or cablesuch as for example a 30-pin cable or an embedded communications devicesuch as an RF module. The device can communicate with a mobile cellulardevice, another device connected to an onboard vehicle data gatheringmodule (e.g., via an OBD-II port as is known in the art), other sensordevices attached to the vehicle, and/or devices used to communicate withthe driver in the vehicle. Interaction between a mobile cellular deviceand the local device 10 may be for the purpose of programming or settingup the local device 10 and/or viewing data from the local device 10.Interaction between a device connected to the OBD-II port and the localdevice 10 may further be established for the purpose of collecting datafrom the vehicle which would otherwise be unavailable but useful withinthe scope of the present disclosure, or even for the purpose of allowingthe local device 10 to operate alternative vehicle functions such as forexample the opening or locking of car doors, windows, trunk, etc. Thisdata may include without limitation vehicle speed, airbag deployment,vehicle braking, and various additional information as may be suppliedfrom the engine control unit (ECU).

Also as previously mentioned, the local device 10 may have a smallbutton associated with the housing for user programming. Alternativelyor in addition, it may be desirable to provide another physicalinput/output port on the device housing such as for example a USB portfor external cable connection and programming, or even a USB cableconnector integral with or otherwise for example extendable from thehousing to establish a connection with a USB port of a programmingdevice. However, in various implementations it may be desirable to omitsuch a physical programming mechanism and instead rely on wirelessprogramming methods. One such method for programming the local device 10may include accessing the hosted user interface (website) where some orall of the device/system parameters may be setup and then a message sentto the local device 10 to adjust the settings. This may generallyinvolve providing a list of programmable settings for user selection,and subsequently providing either a data entry field or a series of userselectable parameters in association with each selected program setting.The predetermined contact information (e.g., telephone numbers) to beused by the local device in case of an accident or other predeterminedextreme event via text messaging (e.g., SMS) can also be programmedthrough the website. The local device may further include anidentification code and/or security code which is further entered viathe website so that for example the website knows which device toprogram or confirms that authorization exists for the same.

In addition, or in the alternative, programming for the local device maybe carried out via a mobile computing device such as for example asmartphone, for example wirelessly or using a hardware connector that isattached to the device. Setup proceeds in substantially the same manneror via similar pathway as that described with respect to the website. Asan alternative to entering a device-specific code, there may in certainimplementations be a predetermined radius of for example several feetaround the local device where a remote device can auto-connect with thelocal device and allow programming through the local device's RF module(or equivalent). This auto-connect feature may be for example triggeredby the depressing of a small-pin sized programming button on the device.

In various implementations, the local device may be programmed tocontinuously collect and transmit data associated with the vehicle tothe host server for storage in the database. Further, the local deviceprocesses vehicle data to determine vehicle status conditions such asfor example an emergency event/accident, or more broadly a drivingstatus which may include safe, unsafe or merely cautionary status modes.In other implementations within the scope of the present disclosure, thevehicle status conditions may be determined remotely on for example thehost server based on received data associated with the vehicle havingbeen transmitted on a more or less continuous basis via thecommunications network.

Referring now to FIG. 9, an exemplary implementation of a method 100 fordetermining an accident condition as a vehicle status may be described.The method 100 may be executed in accordance with a computer programproduct as described above, and the platform for executing datacommunications and program functions included herein may include withoutlimitation an interrupt-driven, event-driven, and/or pollingarchitecture as well as any equivalents as are conventionally known inthe art.

The process may start (at step 102) upon power being initially providedto the local device via vehicle ignition, initial plug-in to the onboardpower source, etc. Once power has been supplied to the device, themicrocontroller waits for acceleration data to be received from theaccelerometer of the local device (step 104). If the acceleration datais greater than a predetermined acceleration threshold of for example3G's (i.e., “no” in response to the query of step 106), the processreturns to step 104 and continues to monitor the acceleration data. Ifan acceleration reading (or alternatively a set of acceleration readingswhere the data may be averaged and filtered for any of various reasons)exceeds the acceleration threshold (i.e., “yes” in response to the queryof step 106), the process continues to step 108 and the vehicle speedmay be determined. In certain implementations the device may rather thanrelying on a predetermined acceleration threshold include neural networkprocessing algorithms for recognizing vehicle acceleration patterns andcomparing current vehicle acceleration data with an accelerationthreshold that has been determined by the microcontroller, perhaps asadjusted from a predetermined initial acceleration threshold in view ofthe recognized patterns.

Upon determining a vehicle speed or a series of two or more vehiclespeed readings (step 108) and storing the vehicle speed reading(s) (step110), the process then determines whether the change in speed isconsistent with an accident in view of for example a change in speedbeing greater than a second predetermined threshold (step 112). If thechange in velocity is less than the second predetermined threshold (orfor example where only one velocity reading has been taken and thereforeno rate of change can be determined) the process is then directed tostep 114. If a subsequent acceleration reading determines that thevehicle acceleration has dropped below the first threshold (i.e., “yes”in response to the query in step 114), the process continues by erasingthe stored velocity data (step 116) and then returns to step 104. If thevehicle acceleration remains above the first threshold (i.e., “no” inresponse to the query in step 114) the process returns to step 108 andthe microcontroller takes additional velocity readings.

If at any point a vehicle acceleration reading is determined to begreater than the first threshold and the change in vehicle velocity isdetermined to be greater than the second threshold (i.e., “yes” inresponse to the query in step 112) the process continues by acquiringposition coordinates for the vehicle via the position sensor/GPS (instep 118) and then reporting the accident pursuant to programmedinstruction by for example transmitting vehicle position data and otherprogrammed data to predetermined personnel such as EMS, family, friends,etc. (in step 120). In this manner detailed feedback regarding specificsof an accident may be provided, such as for example how the accidentoccurred, the order and direction of impacts over the course of theaccident. This information may be used to estimate likely injuries topassengers in the vehicle and assist emergency personnel in allocatingresources for dispatch to the emergency site.

Various additional modes of operation as further described below butwithout limitation to the specific modes recited herein may be activatedby the user via engaging of the main button on the device housing. Thelocal device may be programmed to perform any one or more of the modesupon activation or engaging of the button based for example on userselections via either or both of the host website or a programapplication via a remote computing device (i.e., smartphone handset).

In one exemplary mode of operation, the local device may have beenprogrammed to treat the button as a help button, wherein upon activationof the button by a user the local device transmits an SMS and/or emailmessage to a predetermined number and/or address with for example analert and the location of the vehicle as determined from the GPSreceiver. In an implementation, activation of the button mayautomatically trigger a call to a public safety answering point (i.e.,911), which may be supplemental rather than merely an alternative toother predetermined contacts and/or addresses. The voice call may infact be preferable over the SMS option as a mistaken activation of thebutton may be easily identified by the emergency personnel.

In another exemplary mode of operation, the local device may have beenprogrammed to treat the button as a position indication and notificationbutton, wherein upon activation of the button by a user the local devicetransmits a vehicle location as determined from the GPS receiver to apredetermined location such as for example a social networking siteassociated with the driver, a group, a destination, etc. In this mannera user that is running late for an event may notify others collectivelywithout sending several individual text messages or email messages.

In another exemplary mode of operation, the local device may have beenprogrammed to treat the button as a tracking toggle button, wherein uponengagement of the button by a user a tracking feature is successivelyactivated and deactivated. The tracking feature may include continuoustransmission of vehicle position data and any other appropriate data asreceived or determined by the local device to a remote site such as thehost website. One example of a tracking feature may include the trackingof service personnel, where the local device is plugged into a serviceprovider's vehicle and customers of the service provider who are waitingfor service can use the host website (or alternatively a web portalassociated with the service providers themselves where such features areappropriately established) to actively track the current status of thevehicle along a service route (for example) and better determine whenthey can expect service. In a second example, the local device may beplugged into a delivery vehicle (i.e., mail, FedEx) to facilitate thetracking of packages that have been confirmed as loaded onto theparticular vehicle. The present status of the button (i.e., theunderlying tracking feature) may be indicated to the user by for examplea light or through the use of an audio signal via the speaker.

In another exemplary mode of operation, the local device may have beenprogrammed to treat the button as a business mileage logging button,wherein upon engagement of the button by a user a business mileagelogging feature is successively activated and deactivated. When thefeature is activated, the local device may be programmed to send amessage to a remote program that keeps track of business mileage. Themessage may include a current odometer reading, wherein the remoteprogram can perform business mileage calculations based on a previousmessage and associated odometer reading. Alternatively, the local devicemay be programmed to begin tracking mileage upon a first engagement ofthe button, and upon a second engagement of the button to determine amileage since the first engagement and to transmit a message includingthe determined mileage to a remote program.

In another exemplary mode of operation, the local device may beprogrammed to treat the button as an “I'm Lost” button, wherein uponengagement of the button by a user the local device transmits an emailto a predetermined contact along with the vehicle location on a map anda request to call the user.

In another exemplary mode of operation, the local device may beprogrammed upon engagement of the button by a user to record a soundclip or sound message and subsequently to transmit the recorded soundclip or message to a predetermined destination such as for example oneor more email addresses or a social networking site (i.e., Facebook,Twitter, etc.). The sound clip or message may be recorded for apre-determined length of time after the button has been initiallyengaged, or alternatively the local device may be programmed to record asound clip or message for as long as the button remains engaged by theuser, either by remaining depressed or, as with the tracking feature, byremaining in a toggled “on” or “off” position.

In another exemplary mode of operation, the local device may beprogrammed upon engagement of the button by a user to transmit a messageincluding vehicle location data received via the GPS receiver to apredetermined website. The website may be configured to generate andplace a pin or equivalent indicator on an associated map upon receivingthe message, wherein the user may later access the map and see and labelthe “pins” on the map without forgetting their location. The website mayfurther associate other data such as for example a time stamp, a useridentifier, voice clip taken from the device, etc., with the location“pin”.

Referring now to FIG. 10, in an implementation the local device 10 as acigarette lighter adapter may be replaced by a computer program productinstalled on and executable by a mobile cellular device 54 such as forexample a smartphone. The mobile cellular device 54 may be any of anumber of equivalent devices (such as for example the iPhone by Apple)as are equipped with onboard sensors that in combination with thecomputer program product are effective to provide automatic crashnotification and event data recording within the scope of the presentdisclosure. Such onboard sensors (not further shown in the variousfigures) include but are not limited to the accelerometer/gyroscope, GPSreceiver and microphone.

The computer program product may upon execution by the device 54generate a user interface on the associated display screen by which thevarious parameters for the program may be set by the user, as well asdisplay collected vehicle data, vehicle status information and othervisual indications or cues as programmed. An example of such a visualindication may be a current speed limit for a particular stretch of roadwhich is recognized by the program based on a GPS-determined locationand comparison of the location with that same location on a digital maphaving speed limit data, as may be further described below.

Referring to FIG. 11, another method 200 of detecting a vehicle statusand more particularly an accident condition, as may be performed by acomputer program product executed from a smartphone, may includesupplementing of movement data as described above by further using sounddata.

The previously described method 100 determined an accident based uponacceleration and rate of change in velocity readings that are consistentwith an accident, and consequently with conditions under which airbagdeployment would be expected in theory but without explicitconfirmation. In an effort to eliminate false positives, the data fromthe accelerometer/gyroscope may be substantiated using the microphone todetect the impulse/noise physically generated by airbag deployment or anequivalent sound sufficiently representative of an accident. As embodiedin the algorithms of the computer program product of the presentdisclosure, this allows for the mobile cellular device 54 to detect andexplicitly confirm accidents where for example the airbag is in factdeployed, or at least is determined to have been employed with asubstantially higher degree of certainty.

The process may begin in step 202 by confirming that the mobile deviceis in fact located in a moving vehicle. Since a mobile cellular devicedoes not remain in a vehicle at all times, such an assessment isnecessary to avoid false positives. This can be done by using the GPSreceiver, accelerometer or various combinations of sensors to discernwhen conditions being experienced by the device are consistent withbeing in a vehicle. The real time detection of circumstances allows theapplication to run in the background of the mobile cellular device 54without the program being executed to assess movements for potentialcrashes when otherwise not applicable. In an alternative implementation,however, this step may be omitted or skipped by programming the deviceto perform the vehicle status determination sequence only upon manualexecution of the program by a user rather than automatically detectingvehicle movement.

In an effort to conserve battery life, in various implementations theaccelerometer may be the only sensor that runs the entire time that theprogram product is engaged. Typically, when the program is passivelyrunning in the background it only draws data constantly from theaccelerometer. The data from the accelerometer is used to determine whenthe device 54 (handset) is transported into the interior of a movingvehicle. This change in environment can be discovered using velocity andduration of velocity data, as the speed achieved in a moving vehiclecoupled with the time spent at that speed is only rarely achievedoutside of a moving vehicle. Velocity data can be garnered byintegrating the acceleration data from the accelerometer as the areaunder the acceleration curve is the velocity.

However, while the accelerometer can detect changes in velocity itcannot detect absolute velocity without being made aware of initialvelocity (a reflection of the unknown variable that results whenintegrating). This means that after the program is launched initialvelocity will first need to be calculated by enabling the additionalsensors (step 204) and then using the GPS receiver. Ideally, absolutevelocity would only need to be calculated once when the program isinitiated and after that point would be accurately updated using theaccelerometer data. Due to accuracy issues, however, using theaccelerometer data alone is not sufficient to maintain accurate absolutevelocity. In order to maintain a precise velocity value over time, theinitial velocity may be updated via the GPS receiver. This updateprocess may happen based on a set value that determines how often thisoccurs, such as for example every ten minutes. Assuming that theaccelerometer data indicates the device is in a moving vehicle, theother sensors will start collecting data to aid in the full functioningof the application.

Even when the program is executed and fully functioning in “activemode,” it may continue to check data from the sensors to confirm that itis, in reality, in a moving vehicle (step 206). This continuous checkingserves at least two purposes—it confirms that the judgment to turn onall of the sensors based on accelerometer data was accurate, and furthertriggers the program to turn off the sensors when the data from thesensors indicates that it is no longer in a vehicle (step 208). Upon thesensors determining collectively that the device is no longer in avehicle (or never in fact was), the program returns to passive modewhere it only draws data from the accelerometer.

The process of returning the program to passive mode may in variousimplementations require that the data from the sensors have determinedthat the device is not in a moving vehicle for some predetermined periodof time. This substantially serves to prevent the program from returningto passive mode in congested traffic or other routine stops along theroad.

In an alternative implementation, the process of returning the programto passive data may include a step of determining the user is in aposition associated with the location of a road. This may be performedby for example using map data which has been previously downloaded tothe associated device, or receiving signals from a remote server havingperformed the step which are representative of the user being on or offof such a position. If the determined position of a user does notcoincide with a mapped road location, the process may either determinethat the user is not in a moving vehicle based on the determinedposition alone, or may seek confirmation prior to returning to passivemode, such as for example based on the aforementioned movement dataresults.

The process continues in step 210 when a sound has been detected by theprogram as being consistent with airbag deployment in the vehicle, whilethe program is in active mode. The noises/impulses that the microphonedetects can be interpreted in two fashions, by analyzing the soundsignature (or sound signal) or by detecting the occurrence of a giventhreshold (measured in for example decibels—dB—as is conventionallyknown in the art). The more complex method of sound evaluation involvesmatching the sound signature collected by the microphone to that of asampling of airbag detonation sound profiles. The more simplistic methodof sound evaluation requires a threshold dB to be reached to concludethat the airbag has been deployed. Due to the extremely loud nature ofairbag deployment, the noise can be uniquely identified by a threshold.Airbag deployment generates peak pressures between 167 and 173 dB whichare higher than a typical mobile cellular device such as for example aniPhone can register. This means that in the event of airbag deploymentthe device's microphone will be saturated (for example, the currentversion of the iPhone's microphone saturates at 120 dB). Similar to theiPhone, most cellular phones do not contain microphones that aresensitive enough to accurately measure the pressures/impulses/noisesgenerated by airbag deployment. This means that the microphone in thecellular device 54 can saturate when events other than an airbagdeployment occur, and further explains why sound detection may desirablybe used in conjunction with other data points to detect a crash.

Therefore, in step 212 the process continues by confirming the accidentreading via other device sensors such as the accelerometer, in a mannerwhich in various implementations may be substantially equivalent to thatof the process 100 described above.

If the detected accident condition is not confirmed by other sensors(i.e., “no” in response to the query of step 214) the process returns tostep 206. If the detected accident condition is in fact confirmed byother sensors (i.e., “yes” in response to the query of step 214) theprocess continues to step 216 and the program is triggered to report theaccident in a manner which in various implementations may besubstantially equivalent to that of the process 100 described above.

In accordance with implementations of the present disclosure asdescribed above, the algorithm that assesses accidents may further applya probability algorithm to maximize the efficacy of accident detection.Different values are assigned to the various sensors which are includedand activated at a given time, and their respective indications. Thismay reduce the likelihood of accidents going undetected where not all ofthe sensor inputs indicate the certainty of an accident, while at thesame time substantially avoiding false positives.

In another implementation, a real time feedback method in accordancewith the present disclosure may deliver audible and/or visual cues to adriver after an unsafe driving maneuver has been detected. Regardless ofwhether the local device 10 as a cigarette lighter adapter or the mobilecellular device 54 using the computer program product is being utilizedin accordance with the present disclosure, the vehicle status mayinclude a determination of whether or not the driver is adhering to“safe” driving practices based on for example a comparison of detectedvehicle speeds and/or acceleration with predetermined safety thresholds.Where a mobile cellular device 54 is used to execute the program, or isotherwise available and communicating with a local device 10, the visualcues may be displayed on the display for the device, possibly byflashing an icon or a colored screen. The audible alert, projected outover the speaker built into the handset, may generally be a safer way tocue the driver to risky driving behavior as the audible alert does notrequire the driver to avert their eyes from the road.

Referring now to FIG. 12, an exemplary implementation of a real timefeedback method 300 may begin when an associated local device (i.e.,cigarette lighter adapter) or program product (i.e., in a mobilecellular device) is activated, powered or otherwise enabled to detectvehicle movement, at which time a number of unsafe driving alerts (N)for a particular driving session is reset to zero (step 302). Thedevice/program then begins generating or otherwise obtaining movementdata and position data associated with the vehicle in a mannersubstantially similar to that described above (step 304).

In step 306, the method continues by determining whether or not abruptchanges in velocity or acceleration have exceeded a predeterminedthreshold (safety limit). In the implementation shown, the primarysensor at work in assessing dangerous driving conditions is generallythe accelerometer, as it may easily detect both abrupt increases anddecreases in velocity (i.e., high magnitude acceleration ordeceleration) as key indicators of unsafe driving. Alternatively or inaddition, the GPS receiver may be utilized to provide safety feedback bydetecting vehicle speeds.

If the change in velocity or acceleration is determined to have beengreater than the predetermined threshold (i.e., “yes” in response to thequery in step 306), the method proceeds to step 308 and an unsafedriving alert is generated for the benefit of the driver, which may bevisually and/or audibly generated and provided as previously described.The number of unsafe driving alerts is subsequently incremented (N=N+1)in step 310 and then the new number of unsafe driving alerts is comparedto predetermined threshold number of alerts (step 312). If the number ofunsafe driving alerts that have been generated during a single drivingsession exceeds the predetermined threshold (i.e., “yes” in response tothe query in step 312), the method may in various implementationsproceed by generating and transmitting correspondence such as forexample an email or SMS notification to a predetermined third partyregarding the number of unsafe driving alerts. The email or text messagemay include for example the date, time, location, user name, type ofunsafe driving practice (where available), number of unsafe drivingalerts (N), or any of various other user-selectable options.

If the change in velocity or acceleration is determined to have beenless than the predetermined threshold (i.e., “no” in response to thequery in step 306), the method instead proceeds to step 316 and a storedspeed limit is obtained with respect to a current position for thevehicle, as determined from the position data. The stored speed limitmay be obtained from a digital map or the like which may further bestored in a remote database which is continuously accessed via acommunications network, or at least relevant portions of the map may bestored in a memory on the device 10, 54. Where a speed limit is notstored for the current position, this step can obviously be skipped oromitted. Where a speed limit is available, however, the method thenincludes comparing the instantaneous velocity of the vehicle with theobtained speed limit for the instantaneous position (step 318) todetermine if an unsafe driving event is occurring.

In various implementations, the obtained speed limit may be incrementedby a predetermined “offset” or “buffer” amount which may be set as apercentage (e.g., 10%) or an absolute number (e.g., 10 MPH) such thatthe comparison is actually between the instantaneous velocity of thevehicle and a value corresponding to the buffered speed limit.

If the instantaneous velocity is greater than the stored speed limit, orotherwise the stored speed limit with the predetermined buffer amountapplied thereto (i.e., “yes” in response to the query in step 318), themethod proceeds to step 308 and continues as previously described. Ifthe instantaneous velocity is less than the stored speed limit, orotherwise less than the stored speed limit with the predetermined bufferamount applied thereto (i.e., “no” in response to the query in step318), the method instead moves on to step 320 and the device/program maytransmit the movement data and position data to a remote server such asfor example the host server as described above. In variousimplementations the movement data and position data may be storedlocally, collected and transmitted at periodic intervals rather thancontinuously transmitted. Finally, the method may (in step 322) confirmthat the vehicle is still in transit or otherwise that the real timefeedback program is still active or enabled, consistent with the batteryconservation method as previously described.

As described above, speed limit data may be obtained from a remoteserver and associated database. In accordance with the presentdisclosure, the remote database may in certain implementations includeraw data which has been received or otherwise acquired from a thirdparty such as for example the Department of Transportation (DOT). Bydoing this for every state a complete database of road speed limits canbe acquired and used to populate a hosted or otherwise central remotedatabase for use in real time driver feedback. The database may beconsidered to have substantially correct speed limits in such cases, butsome of the speed limits may become outdated during the time betweendatabase updates being performed by the associated agency.

In various implementations other factors may come into play indetermining unsafe driving maneuvers or circumstances. For example, thevehicle may have sensors or equivalent mechanisms for detectingconditions such as for example nighttime conditions, less-than-desirableweather conditions such as fog, rain and snow, or congested trafficconditions which might heighten the negative effects from unsafedriving. The method 300 may in such implementations be supplemented interms of the number of steps or otherwise to modify the variousthresholds in order to account for the various non-optimal drivingconditions and provide alerts as appropriate.

Referring now to FIG. 13, an exemplary speed limit data-base updatingmethod 400 is described as may be performed by the host server of thepresent disclosure in accordance with device input from a number ofdrivers utilizing local devices 10 or cellular devices 54 running thecomputer program product of the present disclosure. As with othermethods of the present disclosure described herein, in variousimplementations some of the steps may be considered optional orredundant, and the sequence in which the steps are provided may not belimiting unless a first step provides a condition precedent forcontinuation of the method.

The method 400 includes a first step 402 of populating the host databasewith speed limit data from a third party source such as for example theDOT. It may be understood that while a continuous update is preferable,this step may generally not be performed on any kind of a continuousbasis, but rather in accordance with an expected update period asprovided by the third party. Where the third party may for exampleupdate speed limits as they become known rather than provide periodicupdates to the entire database, the host server may be programmed torequest speed limit updates from the third party at predeterminedintervals to encompass changes that have been made in the interim.

The host server then receives movement data and position data from avehicle source (step 404, see also step 320 of FIG. 12) and stores thereceived movement data in association with a location as determined fromthe position data (step 406). Ideally the location may correspond to adatabase portion having speed limit data as populated from the thirdparty source, such as for example a particular stretch of road includingposition coordinates matching those of the received position data. Whereno database portion having speed limit data corresponds to positioncoordinates matching those of the received position data, the method mayinclude a step (not shown) of creating a new database portion associatedwith a new location or otherwise uncharted road or stretch of road withrespect to the latest data from the third party source.

The stored movement data may be aggregated (in step 408) with othermovement data having been previously received and stored with respect tothe same location or associated locations (such as an equivalent stretchof road) to generate for example an average and a median speed recordedfrom that particular location, while still maintaining the individualdata points. In various implementations the movement data may be datedand/or other data of interest appended to the stored data entries, suchthat for example speed limit data from the third party source that isreceived on a particular date is not revised in view of vehicle datathat was previously received and stored. It may be desirable toeliminate data points that are recorded as having been stored for morethan a predetermined amount of time, being for example greater than theinterval for updating the database with data from the third partysource, which may reduce the potential effect of old readings onaggregate.

If a concentrated number of drivers in a particular area provide deviceinput, then the host database may be updated in near real time for thatparticular area. This is possible because the average speed,disregarding outliers, on a given road would theoretically beconsistently deviant from a posted maximum speed limit. Outliers may beeliminated or otherwise disregarded (in step 410) in accordance with afirst threshold deviation value with respect to the remainder of themovement data stored in the host database for a particularlocation/area.

The deviation value may be determined by analyzing the aggregatedmovement data from the plurality of vehicle inputs with respect to alocation/road with a known speed limit. If data points on a given roadare found to be outside of a normal or expected range for the particularspeed limit as indicated by the third party source, the host server mayact by adjusting the speed limit data in the database (step 412). Thedetermination may further include confirming that the plurality ofvehicle inputs satisfy at least a threshold degree of confidence, suchthat for example a sufficient number of readings are available or thatthe number of readings are within a narrow enough band to instill aminimal degree of confidence as needed to support maximum speed limitadjustment in accordance with the present disclosure.

Recall that in describing the real time driver feedback method 300, theprocess included a step (316) of obtaining a stored speed limit for acurrent position, and the stored speed limit may be offset by apredetermined offset or buffer value which may be an absolute offsetvalue or a percentage offset with respect to the stored speed limit. Invarious implementations, the local device 10 or mobile cellular device54 running a computer program product in accordance with the presentdisclosure may obtain an adjusted speed limit value from the host serveras derived using the speed limit database updating method 400 as furtherdescribed herein. In this case, the buffer value may become redundant,as the updated speed limit value inherently represents a safe drivingspeed range as determined from the various data points received, storedand aggregated by the host server in association with that particulararea, which accounts for the buffer value itself with respect to theunderlying fixed speed limit. For example, while generally stated a roadhaving a 55 MPH speed limit may nevertheless be safely navigated at 62MPH in which case a buffer is desirable to prevent unsafe driving alertsat such speeds, a particular stretch of the road may have blind spots,tight curves, or the like, which would eliminate the desirability ofusing a buffer in such cases.

Another case where the buffer value may be considered redundant is wherea process in accordance with the present disclosure is able to rely oninformation from a sufficient number of vehicles on a particular road inreal time. In this case, real time traffic information may affect thedetermination of an unsafe driving alert where for example the variousvehicles are traveling at a mean or median speed with a relatively smalldeviation (e.g., less than a predetermined deviation threshold orotherwise within an associated range based on the detected speeds and apredetermined deviation). A subsequent determination that a particularuser/driver is traveling within the associated range may in such animplementation be considered to overrule an otherwise unsafe drivingcondition, as the driver would be permissibly traveling within the flowof traffic.

In certain implementations, a road safety mapping method may further beperformed by a program executed from the host server, which may be asubset of the speed limit database updating method or otherwiseindependently executed. Such a method includes an algorithm formonitoring accidents and other unsafe driving events (e.g., extremeacceleration/deceleration events) as derived in accordance with methodspreviously described above. The events may be archived on the hostserver or equivalent remote central server. Overlaying the database ofextreme events collected from the various users of the host system on amap using geo-coordinates, tagged to the events, generates a safety map.The safety map indicates locations where users/drivers have hadaccidents or otherwise generated unsafe driving alerts such as wherethey have been determined to have accelerated or decelerated in anextreme fashion. Knowledge of this aggregated data allows users withaccess to it to avoid dangerous roads or junctions when possible and tobe extra alert when having to navigate them. After a large sample ofdata has been collected, road sections and intersections can be mappedin colors indicating their riskiness, much like traffic status iscurrently depicted on may global positioning systems.

In an implementation, systems and methods in accordance with the presentdisclosure may further be able to provide audio and/or visual alerts toa user indicating that a relatively unsafe stretch of road is upcomingor otherwise anticipated (based, e.g., on current heading, speed,alternative roads).

In an implementation, systems and methods in accordance with the presentdisclosure may implement a road safety mapping method as described aboveto determine that unsafe driving practices were used by a driver withrespect to a particular stretch of road, even where not otherwiseaccounted for by the available speed limit data.

In an implementation, systems and methods in accordance with the presentdisclosure may further implement a road safety mapping method asdescribed above to generate an optimal route between a starting pointand an ending point based upon a number of criteria, which may includefor example and without limitation an estimated amount of time needed tonavigate each of a plurality of routes and a road safety value for eachroute. The road safety value may be determined by for exampleaggregating a number of dangerous locations along the route inaccordance with predetermined weighting factors. The road safety valuemay further account for a number of times the driver has been recordedas previously traveling the given route, or data indicating roadconstruction or other current road data that requires accounting.

Once a comprehensive database of road safety data is compiled insurancecompanies may be able to for example evaluate insurance rates takinginto consideration the risk of the roads upon which the policy holderdrives.

While the disclosure has been described in terms of exemplaryimplementations, those skilled in the art will recognize that thedisclosure can be practiced with modifications in the spirit and scopeof the appended claims. These examples are merely illustrative and arenot meant to be an exhaustive list of all possible designs,implementations, applications or modifications of the disclosure.

1-4. (canceled)
 5. A system for use in determining an appropriate amountof resources to be dispatched to an accident site involving a vehicleoperated by a user, the system comprising: a mobile device positionedwithin the vehicle and being associated with the user operating thevehicle, the mobile device including a first set of sensors configuredto generate a first set of data associated with the vehicle; a devicepositioned in the vehicle and communicatively connected with the mobiledevice such that the device is configured to receive at least a portionof the first set of data from the mobile device, the device including asecond set of sensors configured to generate a second set of dataassociated with the vehicle, responsive to the device detecting anoccurrence of an accident involving the vehicle, the device isconfigured to: (i) determine an accident-severity score associated withthe vehicle involved in the accident, the accident-severity score beingbased on a set of accident-severity scoring rules, at least a portion ofthe first set of data, at least a portion of the second set of data, orany combination thereof, and (ii) transmit an output signalrepresentative of the determined accident-severity score; and acomputing device configured to (i) receive the output signal from thedevice and (ii) based on a set of accident-response rules and theaccident-severity score, determine the appropriate amount of resourcesto be dispatched to the accident site involving the vehicle.
 6. Thesystem of claim 5, wherein the determination of the appropriate amountof resources is further based on additional information, the additionalinformation including a type of the vehicle, biometric informationassociated with the user that was collected by one or more sensors priorto the accident, after the accident, or both, an age of the user, aweight of the user, a sex of the user, a medical condition of the user,or any combination thereof. 7-8. (canceled)
 9. The system of claim 5,responsive to the device detecting the occurrence of the accidentinvolving the vehicle, the device is further configured to transmit aninstruction to the mobile device to (i) activate a video camera of themobile device, (ii) activate a microphone of the mobile device, or (iii)both (i) and (ii).
 10. The system of claim 5, responsive to the devicedetecting the occurrence of the accident involving the vehicle, thedevice is further configured to transmit an instruction to the mobiledevice to display, on a display device of the mobile device, insuranceinformation.
 11. The system of claim 5, wherein the determination of theaccident-severity score is at least partially based on (i) a determinedG-force imparted on the vehicle, (ii) a determined direction of impactimparted on the vehicle, (iii) a determined roll position of thevehicle, (iv) a determined yaw position of the vehicle, (v) a determinedchange in vehicle facing position, or (vi) any combination thereof. 12.The system of claim 5, wherein the first set of sensors includes amovement sensor, a position sensor, an image sensor, an electronic nosesensor, a vital sign detector, an audio sensor, or any combinationthereof, and wherein the second set of sensors includes a movementsensor, a position sensor, an image sensor, an electronic nose sensor, avital sign detector, an audio sensor, or any combination thereof. 13-17.(canceled)
 18. The system of claim 12, prior to the transmitting of theoutput signal, the device is further configured to determine, via theelectronic nose sensor of the second set of sensors, if a substance ispresent in the vehicle and responsive to the device determining that thesubstance is present in the vehicle, modify the determinedaccident-severity score.
 19. The system of claim 18, wherein thesubstance is gasoline, fuel, natural gas, smoke, fire, or anycombination thereof.
 20. The system of claim 12, prior to thetransmitting of the output signal, the device is further configured todetermine, via the position sensor of the second set of sensors, ageo-location of the vehicle and responsive to the device determining thegeo-location of the vehicle, modify the determined accident-severityscore.
 21. The system of claim 20, wherein the determining of thegeo-location includes a determination of (i) whether the vehicle islocated on a road having a speed limit that is greater than or less thana predetermined or pre-calculated miles per hour, (ii) whether thevehicle is more than or less than a predetermined or pre-calculatedmiles from a hospital, or (iii) both (i) and (ii).
 22. A method ofdetermining an appropriate amount of resources to be dispatched to anaccident site involving a vehicle operated by a user, the methodcomprising: generating, via a first set of sensors of a device, a firstset of data associated with the vehicle; receiving, via a communicationsmodule of the device, a second set of data, the second set of data beinggenerated via a second set of sensors of a mobile device positionedwithin the vehicle; detecting an occurrence of an accident involving thevehicle; responsive to the detecting, determining an accident-severityscore associated with the vehicle involved in the accident, theaccident-severity score being based on a set of accident-severityscoring rules, at least a portion of the generated first set of data, atleast a portion of the received second set of data, or any combinationthereof; transmitting, via the communications module of the device, anoutput signal representative of the determined accident-severity score;and determining, based on a set of accident-response rules and theaccident-severity score, the appropriate amount of resources to bedispatched to the accident site involving the vehicle.
 23. A system foruse in determining an accident-severity score for an accident involvinga first vehicle operated by a first user and a second vehicle operatedby a second user, the system comprising: a first device positioned inthe first vehicle, the first device including a first set of sensorsconfigured to generate a first set of data associated with the firstvehicle, responsive to the first device detecting an occurrence of afirst accident involving the first vehicle, the first device isconfigured to: (i) determine a first accident-severity score associatedwith the first vehicle involved in the first accident, the firstaccident-severity score being based on a set of accident-severityscoring rules and a first portion of the first set of data, and (ii)transmit a second portion of the first set of data and a first outputsignal representative of the determined first accident-severity score; asecond device positioned in the second vehicle, the second deviceincluding a second set of sensors configured to generate a second set ofdata associated with the second vehicle, responsive to the second devicedetecting an occurrence of a second accident involving the secondvehicle, the second device is configured to: (i) determine a secondaccident-severity score associated with the second vehicle involved inthe second accident, the second accident-severity score being based onthe set of accident-severity scoring rules and a first portion of thesecond set of data, and (ii) transmit a second portion of the second setof data and a second output signal representative of the determinedsecond accident-severity score; a computing device configured to (i)receive the first output signal from the first device, (ii) receive thesecond output signal from the second device, (iii) receive the secondportion of the first set of data, (iv) receive the second portion of thesecond set of data, (v) determine, based at least in part on thereceived second portion of the first set of data and the received secondportion of the second set of data, that the first accident is the sameas the second accident, and (vi) responsive to the determination thatthe first accident is the same as the second accident, modify thedetermined first accident-severity score, the determined secondaccident-severity score, or both.
 24. The system of claim 23, whereinthe modification is based at least in part on additional information,the additional information including a type of the first vehicle, a typeof the second vehicle, biometric information associated with the firstuser, biometric information associated with the second user, an age ofthe first user, an age of the second user, a weight of the first user, aweight of the second user, a sex of the first user, a sex of the seconduser, a medical condition of the first user, a medical condition of thesecond user, or any combination thereof.
 25. The system of claim 24,wherein the additional information is received by the computing devicefrom the first device, from the second device, or a combination thereof.26. The system of claim 23, wherein the computing device is furtherconfigured to determine an appropriate amount of resources to bedispatched to the accident site involving the first vehicle and thesecond vehicle based on (i) a set of accident-response rules, (ii) thefirst accident-severity score, (iii) the modified firstaccident-severity score, (iv) the second accident-severity score, (v)the modified second accident-severity score, (vi) or any combinationthereof.
 27. The system of claim 23, wherein the first portion of thefirst set of data is different than the second portion of the first setof data and wherein the first portion of the second set of data isdifferent than the second portion of the second set of data.
 28. Thesystem of claim 23, further comprising: a first mobile device positionedwithin the first vehicle and being associated with the first useroperating the first vehicle, the first mobile device including a thirdset of sensors configured to generate a third set of data associatedwith the first vehicle, the first mobile device being communicativelyconnected with the first device such that the first device is configuredto receive at least a portion of the third set of data from the firstmobile device; and a second mobile device positioned within the secondvehicle and being associated with the second user operating the secondvehicle, the second mobile device including a fourth set of sensorsconfigured to generate a fourth set of data associated with the secondvehicle, the second mobile device being communicatively connected withthe second device such that the second device is configured to receiveat least a portion of the fourth set of data from the second mobiledevice.
 29. The system of claim 28, wherein the first accident-severityscore is further based on at least a portion of the third set of dataand wherein the second accident-severity score is further based on atleast a portion of the fourth set of data.
 30. The system of claim 28,responsive to the determination that the first accident is the same asthe second accident, the computing device is further configured totransmit first information associated with the first user to the secondmobile device and transmit second information associated with the seconduser to the first mobile device.